软件开发的一个迭代周期中的四个工作流:
A-业务建模——定位需要改进的目标组织(人群或机构)以及该组织接下来最需要改进的问题。B-需求——描述为了改进组织的问题,所引入的信息系统必须具有的整体表现。C-分析——提炼为了满足功能需求,所引入的信息系统需要封装的核心域机制。D-设计——考虑质量需求和设计约束,将核心域机制映射到选定非核心域上实现。很多开发人员只有D的知识,当岗位发生变化,需要他做A、B、C的工作时,按道理应该去认真学习A、B、C的技能才对。但是,很多人并不愿意走出自己的舒适区,甚至还会有意无意地把其他人拉到自己的舒适区。(1)在和涉众讨论需求时,频频蹦出一些“技术潮词”,目的就是以自己的“所长”来碾压涉众,从而掩盖自己业务建模和需求技能的不足。(2)在讨论核心域的类模型时,动不动就谈到如何实现或者质疑“会不会有性能问题”,从而掩盖自己抽象能力的不足。(3)为了掩盖自己的无知,在不好好学习相关建模技能的情况下去做需求、分析相关的工作时,喜欢在各种用词前面加上“业务”、“用户”等词汇,显得咱搞“技术”的大爷多么亲民啊,都低下头来和你谈业务、谈用户了!例如,有的DDD文章也使用用例的概念,却是“不学有术”,言则称“业务用例”,作者可能觉得:我在说用例时没有谈到“技术”嘛,所以用例自然就是“业务”的了!感兴趣的读者可以自行搜索关键词:DDD "业务用例"。类似的还有,在“需求”前面加“业务”,变成“业务需求”,加上“用户”,变成“用户需求”,以表示自己对业务、用户的重视。最近几年,领域驱动设计被胡乱吹捧,所以,流行的前置词又多了一个“领域”。知乎上的这篇阅读量还比较大的DDD文章,先不说“领域模型……反映需求的本质”是错误的,就看这个累计叠加了三个前置词的“领域内用户业务需求的本质”就叹为观止了。
大家可以观察造词圈子产出的各种文章,看看有没有我说的现象。[讲解再更新]31套UML/SysML+EA/StarUML的建模示范视频-全程字幕(20221201更新)
[周末上课]1月7-8日分析设计高阶-网络公开课(原“剔除伪创新的领域驱动设计”)
《软件方法》书中自测题-题目全文+分卷自测(1-8章)16套111题
《软件方法》强化自测题集110题
CTO也糊涂的常用术语:功能模块、业务架构、用户需求……[20210217更新]
如何选择UMLChina服务
作者微信:umlchina2